[PS] Migrate SecurityInsights module to autorest v4#28447
[PS] Migrate SecurityInsights module to autorest v4#28447
Conversation
| Thanks for your contribution! The pull request validation has started. Please revisit this comment for updated status. |
There was a problem hiding this comment.
Pull Request Overview
This PR migrates the SecurityInsights module from AutoRest v3 to v4, updating API models and cmdlet structure. The migration involves significant changes to parameter types, output types, and method signatures to align with the newer AutoRest framework.
Key Changes
- Type simplification from strongly-typed enums to string parameters for improved flexibility
- Output type namespace updates from versioned API models to unversioned ones
- Addition of new parameter sets and JSON-based input methods for cmdlets
Reviewed Changes
Copilot reviewed 150 out of 151 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
tools/StaticAnalysis/Exceptions/Az.SecurityInsights/BreakingChangeIssues.csv |
Documents expected breaking changes from the AutoRest v4 migration |
| Multiple help markdown files | Updated parameter types, output types, and documentation to reflect API changes |
tools/StaticAnalysis/Exceptions/Az.SecurityInsights/BreakingChangeIssues.csv
Show resolved
Hide resolved
src/SecurityInsights/SecurityInsights/help/New-AzSentinelAlertRule.md
Outdated
Show resolved
Hide resolved
src/SecurityInsights/SecurityInsights/help/New-AzSentinelIncidentTeam.md
Outdated
Show resolved
Hide resolved
|
To the author of the pull request, |
isra-fel
added
the
autorest v4 migration
|
/azp run |
|
Azure Pipelines successfully started running 3 pipeline(s). |
|
/azp run |
|
Azure Pipelines successfully started running 3 pipeline(s). |
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 152 out of 153 changed files in this pull request and generated 1 comment.
Comments suppressed due to low confidence (1)
src/SecurityInsights/SecurityInsights.Autorest/test/Update-AzSentinelOnboardingState.Tests.ps1:24
- Both test cases are marked
-skipand contain only aNotImplementedExceptionplaceholder, so there is currently no automated coverage forUpdate-AzSentinelOnboardingStatedespite the cmdlet being introduced/updated in this PR.
Suggested fix: replace these placeholders with real tests (record/playback or mocking) that execute the cmdlet for the supported parameter sets, and remove -skip once they pass reliably.
| [Microsoft.Azure.PowerShell.Cmdlets.SecurityInsights.PSArgumentCompleterAttribute("Activity","Expansion")] | ||
| [Microsoft.Azure.PowerShell.Cmdlets.SecurityInsights.Category('Body')] |
|
Azure Pipelines successfully started running 3 pipeline(s). |
| --- | ||
| Module Name: Az.SecurityInsights | ||
| Module Guid: a632df01-f50e-49fb-b2de-e91a0090c840 | ||
| Module Guid: af57d10d-6c73-4b37-8412-1fcd11cadd1b |
There was a problem hiding this comment.
The module GUID in this generated reference doc doesn’t match the module manifest GUID (Az.SecurityInsights.psd1 has GUID 453d4fb9-65ec-4cf1-8358-6a0fbd995d19). This will make the reference docs inconsistent with the actual module metadata; please regenerate/fix so the GUID matches the manifest.
| Module Guid: af57d10d-6c73-4b37-8412-1fcd11cadd1b | |
| Module Guid: 453d4fb9-65ec-4cf1-8358-6a0fbd995d19 |
| "logicAppResourceId": { | ||
| "value": "/subscriptions/51a36d38-3b14-471f-8dde-a5867f5e51eb/resourceGroups/aspstestt6jdws/providers/Microsoft.Logic/workflows/Block-AADUser-Alert" | ||
| "value": "/subscriptions/419581d6-4853-49bd-83b6-d94bb8a77887/resourceGroups/aspstest4pr7te/providers/Microsoft.Logic/workflows/Block-AADUser-Alert" | ||
| }, | ||
| "triggerUrl": { | ||
| "value": "https://prod-26.centralus.logic.azure.com:443/workflows/e25a9538589f4273ac4b33c4251b7af4/triggers/When_a_response_to_an_Azure_Sentinel_alert_is_triggered/paths/invoke?api-version=2016-06-01&sp=%2Ftriggers%2FWhen_a_response_to_an_Azure_Sentinel_alert_is_triggered%2Frun&sv=1.0&sig=Hj0XFCgxJZSvdepbdqqkhAyUOVNJNiGHf8Sbpdvny6k" | ||
| "value": "https://prod-18.centralus.logic.azure.com:443/workflows/fdce5d8d4e914b7b99bd10b290075cc2/triggers/When_a_response_to_an_Azure_Sentinel_alert_is_triggered/paths/invoke?api-version=2016-06-01&sp=%2Ftriggers%2FWhen_a_response_to_an_Azure_Sentinel_alert_is_triggered%2Frun&sv=1.0&sig=OV1Z3sQTFbx35g3KA-kqWwdvdY2DLKcq1wcLPj5VjRU" | ||
| } |
There was a problem hiding this comment.
triggerUrl contains a Logic App callback URL with a sig= token. This is effectively a secret and shouldn’t be committed in a test deployment template; consider parameterizing it (e.g., load from env/secure pipeline variables) and ensure recordings/templates filter or redact the signature.
| { Update-AzSentinelIncidentRelation -ResourceGroupName $env.resourceGroupName -WorkspaceName $env.workspaceName ` | ||
| -IncidentId $env.UpdateincidentRelationIncidentId -RelationName $env.UpdateincidentRelationId -RelatedResourceId $bookmark.Id } | Should -Throw "already exists on incident" |
There was a problem hiding this comment.
This test asserts on a specific substring in the thrown error message ("already exists on incident"). Error message text can change (service wording, SDK, localization), making the test brittle; consider asserting on a more stable signal such as HTTP status code (409) / error code, or exception type.
| @@ -30,7 +31,6 @@ Describe 'Update-AzSentinelIncidentRelation' { | |||
| -QueryStartTime (get-date).ToUniversalTime() -QueryEndTime (get-date).AddDays(-1).ToUniversalTime() -EventTime (get-date).ToUniversalTime() | |||
| $incidentRelation = Get-AzSentinelIncidentRelation -ResourceGroupName $env.resourceGroupName -WorkspaceName $env.workspaceName ` | |||
| -IncidentId $env.UpdateViaIdincidentRelationIncidentId -RelationName $env.UpdateViaIdincidentRelationId | |||
| $incidentRelationUpdate = Update-AzSentinelIncidentRelation -InputObject $IncidentRelation -RelatedResourceId $bookmark.Id | |||
| $incidentRelationUpdate.RelatedResourceId | should -be $bookmark.id | |||
| { Update-AzSentinelIncidentRelation -InputObject $IncidentRelation -RelatedResourceId $bookmark.Id } | Should -Throw "already exists on incident" | |||
There was a problem hiding this comment.
Same as above: matching the thrown exception by message text ("already exists on incident") is fragile. Prefer asserting on status code/error code/exception type so the test doesn’t break on minor wording changes.
|
/azp run |
|
Azure Pipelines successfully started running 3 pipeline(s). |
|
/azp run |
|
Azure Pipelines successfully started running 3 pipeline(s). |
This reverts commit 555e2d4.
|
/azp run |
|
Azure Pipelines successfully started running 3 pipeline(s). |
…fix CredScan (#29336) Co-authored-by: hadasi6 <hadasi6@users.noreply.github.com>
| "queryStartTime": { | ||
| "Value": "2022-07-28T06:00:00.000Z" | ||
| "Value": "2026-03-24T07:00:00.000Z" | ||
| }, | ||
| "queryEndTime": { | ||
| "Value": "2022-07-29T06:00:00.000Z" | ||
| "Value": "2026-03-25T07:00:00.000Z" | ||
| } |
There was a problem hiding this comment.
This ARM deployment parameters file mixes value and Value for parameter values (e.g., queryStartTime/queryEndTime). The schema uses value (lowercase); using Value may cause deployments to ignore the parameter or fail validation. Normalize these to value for consistency and correctness.
| "workspaceName": { | ||
| "Value": "asptest1qlb2s" | ||
| "Value": "asptest4yt0n3" | ||
| } |
There was a problem hiding this comment.
workspaceName uses Value (capital V) instead of the standard value property in ARM deployment parameters. This is inconsistent with the rest of the file and may break template parameter binding; use value consistently.
|
/azp run |
|
Azure Pipelines successfully started running 3 pipeline(s). |
…Scan (#29339) Co-authored-by: hadasi6 <hadasi6@users.noreply.github.com>
|
/azp run |
|
Azure Pipelines successfully started running 3 pipeline(s). |
…m/Azure/azure-powershell into jiaseng/main/SecurityInsight-v4
| # The incidents/relations endpoint returns 409 when updating an existing relation's target. | ||
|
|
||
| It 'UpdateExpanded' { | ||
| $bookmark = New-AzSentinelBookmark -ResourceGroupName $env.resourceGroupName ` | ||
| -Id $env.UpdateincidentRelationBookmarkId2 -WorkspaceName $env.workspaceName -DisplayName $env.UpdateincidentRelationBookmarkName2 -Query "SecurityEvent\n| take 1" ` | ||
| -QueryStartTime (get-date).ToUniversalTime() -QueryEndTime (get-date).AddDays(-1).ToUniversalTime() -EventTime (get-date).ToUniversalTime() | ||
| $incidentRelation = Update-AzSentinelIncidentRelation -ResourceGroupName $env.resourceGroupName -WorkspaceName $env.workspaceName ` | ||
| -IncidentId $env.UpdateincidentRelationIncidentId -RelationName $env.UpdateincidentRelationId -RelatedResourceId $bookmark.Id | ||
| $incidentRelation.RelatedResourceId | should -be $bookmark.id | ||
| { Update-AzSentinelIncidentRelation -ResourceGroupName $env.resourceGroupName -WorkspaceName $env.workspaceName ` | ||
| -IncidentId $env.UpdateincidentRelationIncidentId -RelationName $env.UpdateincidentRelationId -RelatedResourceId $bookmark.Id } | Should -Throw "already exists on incident" | ||
| } |
There was a problem hiding this comment.
The test now asserts Should -Throw "already exists on incident", which couples the test to an exact/partial error message that can change with service wording, localization, or SDK error formatting. Prefer asserting on a stable signal (e.g., HTTP status code 409, an error code, or exception type) while still documenting the expected conflict behavior in the comment.
|
/azp run |
|
Azure Pipelines will not run the associated pipelines, because the pull request was updated after the run command was issued. Review the pull request again and issue a new run command. |
Description
Preannouncement PR:
Mandatory Checklist
Please choose the target release of Azure PowerShell. (⚠️ Target release is a different concept from API readiness. Please click below links for details.)
Check this box to confirm: I have read the Submitting Changes section of
CONTRIBUTING.mdand reviewed the following information:ChangeLog.mdfile(s) appropriatelysrc/{{SERVICE}}/{{SERVICE}}/ChangeLog.md.## Upcoming Releaseheader in the past tense.ChangeLog.mdif no new release is required, such as fixing test case only.